Skip to content

Conversation

@RyanL1997
Copy link
Collaborator

@RyanL1997 RyanL1997 commented Oct 25, 2025

Description

Fix CVE-2025-48924

The problematic dependency happens to be in a diamond dependency situation:

  ├── commons-lang3:3.18.0  <- correct version already
  └── calcite-core:1.38.0
      └── aggdesigner-algorithm:6.0
          └── commons-lang:2.4  <- reported version

Related Issues

Check List

  • New functionality includes testing.
  • New functionality has been documented.
  • New functionality has javadoc added.
  • New functionality has a user manual doc added.
  • New PPL command checklist all confirmed.
  • API changes companion pull request created.
  • Commits are signed per the DCO using --signoff or -s.
  • Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Signed-off-by: Jialiang Liang <[email protected]>
Copy link
Collaborator

@dai-chen dai-chen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both common-lang3 3.18 and common-lang 2.6+ can fix the CVE right? Is current change enforcing common-lang3 which rename its root package?

@RyanL1997
Copy link
Collaborator Author

RyanL1997 commented Oct 27, 2025

Both common-lang3 3.18 and common-lang 2.6+ can fix the CVE right? Is current change enforcing common-lang3 which rename its root package?

Hi @dai-chen ,

You're correct that there are no patched versions in the commons-lang 2.x series (the advisory shows "Patched versions: None" for commons-lang 2.0-2.6). The only fix is upgrading to commons-lang3 3.18.0+.

Yes, our dependency substitution does enforce commons-lang3 which uses the renamed org.apache.commons.lang3.* package structure, but our testing confirms this works correctly. Since there's no way to patch the old commons-lang 2.x and we can't control what aggdesigner-algorithm depends on, dependency substitution to commons-lang3 3.18.0 is the approach to resolve this.

@Swiddis Swiddis merged commit fcff083 into opensearch-project:main Oct 29, 2025
37 checks passed
@LantaoJin
Copy link
Member

@RyanL1997 can you explain how this problem happens again? I had excluded the commons-lang in https://github.com/opensearch-project/sql/pull/3895/files

@opensearch-trigger-bot
Copy link
Contributor

The backport to 2.19-dev failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/sql/backport-2.19-dev 2.19-dev
# Navigate to the new working tree
pushd ../.worktrees/sql/backport-2.19-dev
# Create a new branch
git switch --create backport/backport-4665-to-2.19-dev
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 fcff083fd1a8b15686c22cf7decb80ec6fd620fd
# Push it to GitHub
git push --set-upstream origin backport/backport-4665-to-2.19-dev
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/sql/backport-2.19-dev

Then, create a pull request where the base branch is 2.19-dev and the compare/head branch is backport/backport-4665-to-2.19-dev.

@RyanL1997
Copy link
Collaborator Author

@RyanL1997 can you explain how this problem happens again? I had excluded the commons-lang in #3895 (files)

Hi @LantaoJin, in the PR you mentioned:

// Force commons-lang3 version when requested
resolutionStrategy.force 'org.apache.commons:commons-lang3:3.18.0'

// Exclude commons-lang from calcite-core specifically  
exclude group: 'commons-lang', module: 'commons-lang'

The fix you did works for direct dependencies and the calcite-core case you identified. However, resolutionStrategy.force only applies when commons-lang3 is specifically requested, and the exclude only removes commons-lang from that one dependency. (In other word, the case I mentioned in this PR description will not be covered.)

Based on your previous fix, mine provides global substitution - ANY request for commons-lang:commons-lang from anywhere in the transitive dependency tree gets automatically replaced with the safe version of commons-lang3:3.18.0.

So your fix handled the known cases, and the substitution acts as a safety net for any other transitive dependencies that might still pull in the vulnerable 2.x version. Both pieces were needed for this complete fix.

@LantaoJin LantaoJin added the backport-manually Filed a PR to backport manually. label Oct 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport 2.19-dev backport-failed backport-manually Filed a PR to backport manually. maintenance Improves code quality, but not the product

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants